An Evaluation of DRete on CUPlD for OPSS Matching

Rising interest in production systems has led to a number of research efforts aimed at increasing their execution speed. The bottleneck in current implementations is the matching required during each production cycle. CUPID is a multiprocessor architecture designed to execute OPS5 matching using DRete, a distributed version of the Rete matching algorithm. This paper describes CUPID and the DRete algorithm with emphasis on correctness and effectiveness in exploiting parallelism in the match operation. The Monkey and Bananas program was executed on a CUPID simulator running the DRete algorithm. The results show that on a technology-independent comparison basis, and in measured execution speed, that the CUPID/DRete combination is several times faster than a commercial uniprocessor, a VAX 11/785, running compiled OPS83. 1 . I n t r o d u c t i o n With the increasing use of production systems, there is growing interest in improving their execution speed. A number of researchers are working toward this goal, some concentrating on customized uniprocessor designs[Quin85,Lehr86] and others on multiprocessor architectures[Hill84,Stol84,Ramn86,Gupt87,Oshi87]. The work reported here involves the CUPID[Kell87] multiprocessor architecture running a distributed matching algorithm, DRete [Kell87b]. DRete and CUPID were designed in tandem, each taking advantage of characteristics of the other to ensure optimum performance from the union of the two. DRete is based on the Rete[Forg82] algorithm, a many-pattern/many-object matching algorithm designed for the OPS family of production languages running on a uniprocessor. The performance of CUPID executing DRete has been assessed with respect to expected performance and theoretical limitation,and using a test simulation. The simulated program is the Monkey and Bananas problem. It was chosen because it has been used in the past to grade the performance of several machines, although it does not contain a high potential for parallelism. The OPS program used is shown as an example in the OPS83 User's Guide[Forg85]. As a basis for comparison, this program was also run on a VAX 11/785 using a standard OPS83 compiler. The next section contains a brief review of production languages, the OPS family in particular, and the Rete matching algorithm. The following two sections describe the DRete algorithm and the CUPID architecture. Sections 5 and 6 give details of the simulator and the simulation results and section 7 is a discussion of these results and their implications. 2. OPS Produc t ion Languages and Rete Match ing A production system consists of three parts: 1) a set of rules, or productions, defining available operations on a problem state, 2) a set of data elements,or working memory, which describe the current problem state, and 3) a control mechanism which applies the rules to the data elements. Each rule is made up of a condition portion, describing the situation it applies to, and an action portion, describing operations to be performed on the data. It is the responsibility of the control mechanism to determine which rules apply at a particular time by matching the data elements to the rule conditions. From the result of the match — the conflict set — the most appropriate rule is selected — conflict resolution — and fired. Firing a rule changes the data, which invalidates the match. The match must be recomputed before another rule can be selected and so execution proceeds in a cycle of match, conflict resolution and rule firing phases. Of the three phases described, the match phase is by far the most computationally expensive[Forg84]. The Rete algorithm reduces the actual number of match operations done by taking advantage of similarities among rule conditions, and the fact that each rule